/** 
	\mainpage CVM: The Chickadee Virtual Machine

	The Chickadee Virtual Machine (CVM) is a 
	general purpose byte-code virtual machine intended for use 
	as a target from programming languages with object-oriented 
	and/or functional programming features.

	The CVM architecture is designed to be appropriate for embedding 
	in host applications or computing environments where 
	resource constraints are quite extreme. It has a very small
	executable footprint (e.g. approximately 16k on Windows) 
	and has programs with a compact byte-code representation.

	Despite its particularly small size the CVM supports a rich set 
	of features natively including garbage collection, dynamic arrays,
	hash tables, coroutines, continuations, and closures.

	One of the more interesting features of CVM is the ability 
	to capture the entire state of the VM in a serializable binary
	format and to restore it a later point. 

	\li \subpage features
	\li \subpage applications
	\li \subpage design
	\li \subpage lineage
	\li \subpage support
	\li \subpage opcodes

	\page applications Applications of the CVM

	There are a number of potential applications for the CVM. Some of 
	the more promising areas that have been identified are:

	\li Distributed computing - The CVM allows the entire state of 
		the VM to be captured, serialized, deserialized, and then 
		resumed from another VM instance. This combined with the 
		compact representation of programs can be very useful 
		for hosting in applications built for distributed or 
		cloud computing. 

	\li Embedded computing - The small size of programs converted 
		to CVML, and the relatively small size of the CVM executable
		make it appropriate for use on severely resource constrained 
		devices.

	\li Shared memory parallel devices (e.g. multi-core PCs) - 
		Because the CVM uses no static shared data structures, 
		multiple CVM instances can be safely run in the same process 
		space on multiple threads without synchronization. 

	\page design Design and Architecture of the CVM

	The CVM and CVML are intended for use as language agnostic
	targets. They provide a rich set of features required for 
	a large set of programming languages.

	The design of this implementation of the CVM heavily 
	emphasizes a compact and simple implementation over 
	raw performance. 
	
	The opcode set used by the CVM, the CVML, 
	is designed to for small program representations over raw 
	performance. For example, rather than having arithmetic 
	operations for each of the intrinsic types (e.g. float, int, etc.)
	we use single opcodes. This is potentially slower (depending on the CVM
	implementation strategy). 
	but ultimately requires less space in the byte-code representation. 

	\section trycatch Try/Catch

	The try function must contain the code for removing the markers
	on the stack and auxilary stack, as well as the catch function from the main 
	stack (just below the marker). In other words, the try block must 
	terminate with "pop pop popaux ret".

	\section return Function Termination

	All functions must have a terminating opcode in the last position. This 
	is either \c ret, \c halt, or \c tail. 

	\page features Features of the CVM

	Notable features of the CVM:
	
	\li Serializable continuations - Built-in support for continuations
		that can be serialized and deserialized. Allows the entire 
		state of the VM to be captured, distributed, and restored.

	\li Garbage collector - The GC use a hybrid approach of 
		both reference counting and a mark and sweep collector.
	
	\li Thread-safe VM instantiations - No static data is used so 
		multiple instances of the VM can be run in the same process space
		with no chance of deadlocks, race condition. or performance
		degradation. 
	
	\li Support for closures - Functions are first class objects, and can 
		be bound arguments (e.g. via currying or partial application).  

	\li Tail-call optimization (TCO) - Function calls in tail position 
		are optimized so that deep recursive calls do not 
		cause a stack overflow. As a result tail-calls are effectively 
		structured go-to statements.  

	\li Hash tables - There is built-in support for hash table data 
		structures. 
	
	\li Dynamic arrays - There is built-in support for arrays that grow 
		and shrink dynamically. 

	\page lineage The Lineage of CVM

	CVM is the successor of the Cat programming language. Cat was intended 
	as an exploration of the design space of languages that are functional,
	stack-based languages, and that support type-inference. 
	
	Cat was heavily inspired by the Joy language and borrowed liberaly 
	from it. Other influencing languages in the design of Cat and CVM 
	are PostScript, FORTH, Java bytecode, CLI bytecode, ML, Haskell, Lisp,
	Scheme, J and K. 

	\page support Licensing and Support

	The CVM is an open-source project licensed under the MIT License 1.0. 
	Other licenses are available upon request. The CVML has been under continuous 
	development since 2006 	counting the preliminary work done on Cat. I 
	expect active development to continue into the forseeable future. 

	So far the CVML has been a single person endeavour and has no sponsorship, 
	so while development is steady and continuous, it is slow. I am interested in 
	forming partnerships with academia or industry. I am also 
	available for consulting services. 
	
	For more information please contact Christopher Diggins at 
	cdiggins@gmail.com.

	\page collections Collections

	In the CVM there are several different kinds of collection.

	\li Objects - An object has type ObjectType, a pointer to a dynamic array 
		of objects, and a pointer to a vtable. The vtable is any type of value.
		An object also acts list a stack, in that it support pushing and popping 
		of values. 
	\li Table - A table has type TableType, and is implemented internally as a hash table
		with quadratic probing for collision resolution.
	\li Vector - The folllowing vector types are supported: byte (VByte), int (VInt), 
		float (VFloat) and double (VDouble). Vectors are accessed as if they are objects.
	\li Sequence - Includes objects and vectors.
	\li Pair - A pair can be used for creating linked lists, similar to the cons cell 
		in Lisp.
	\li Functions - A function contains both a pointer to code and an array. It is
		similar to an object.

	\page todo List of Todo items

	\todo Move all memory handling to the memory management module (include mallocs / callocs)
	\todo Proper strategy for catastrophic failure.
	\todo Document how to extend the VM.
	\todo Figure out how to deal with intrinsic functions.
	\todo Document how code is organized. 
	\todo Explain how to compile a language to the VM.
	\todo Bootstrap a simple assembler in CVM. 
	\todo Come up with a marshalling or pickling strategy. 
	\todo Vectors versus objects as lists.
	\todo Explain how to make a coroutine. 
	\todo Explain how objects can be prototype based (like JavaScript) or Java/C++ style.
	\todo Write some basic list handling libraries. 
	\todo Write an optimized vector library
	\todo Write a math library extension.
	\todo Write some basic lisp-style list routines.
	\todo Explain how to optimize for pure functional languages. 
	\todo Write a mini-Python interpreter
	\todo Write a mini-Lua interpreter
	\todo Write a mini-JavaScript interpreter
	\todo Write a mini-C interpreter
	\todo Write a mini-Java interpreter
*/

#include "cvm.h"

/** Used as a special reserved value to mark a place on the stack. This is used 
	by exceptions when they have to restore the stack. */
static Val marker;

// The implementation is broken up into a number of inline files.
// This makes it slightly easier for the compiler to optimize the 
// whole program rather than creating a number of separate 
// compilation units that are linked. 

#include "array.inl"
#include "val.inl"
#include "vec.inl"
#include "seq.inl"
#include "mem.inl"
#include "table.inl"
#include "vm.inl"
#include "arithmetic_eval.h"
#include "serialize.inl"
#include "vm_eval.inl"

